Applications based on microservices architecture, also referred to herein as microservices-based applications, are becoming increasingly popular. In such architecture, an application is broken down into independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business purpose. These independently deployable modular services are referred to herein as ‘microservices’. In effect, a microservice is an application with a single function, such as routing network traffic, making an online payment or checking inventory. Each microservice is stateless and has multiple instances for availability and scale, so it is possible to stop and redeploy individual instances of a microservice without impacting the overall application.
Typically, logic for each microservice, or more specifically the logic for each microservice instance, is encapsulated in a software package generally referred to as a container. The container provides the necessary environment including code, runtime, system tools, system libraries, etc. for the microservice instance to run. In a containerized application, each microservice instance runs in its own container, and several containers can share a common pool of hosts. The containers can be from the same application, or from different applications. The containers provide fast deployment times, typically in milliseconds once the microservice image is downloaded and cached on a container host. Such combination of stateless services deployed in containers, enables rapid and dynamic adjustment of the application.
Generally, the deployment of microservice instances in hosts is based on an initial set of constraints such as CPU shares required, memory required, disk space required, affinity or anti-affinity with other microservice instances, etc. As such, defining valid constraints involves time consuming experimentations and, in many cases, also guesswork. The constraints are typically evaluated during initial deployment of microservice instances in hosts. In many example environments, such as for example in cloud environments, resources are shared across several services and applications and it is fairly common to run hundreds of microservices, each with three or more instances, across hundreds of container hosts. In such a scenario, the deployment of microservice instances based on the initial set of constraints may lead to sub-optimal application performance overtime, due to variations in underlying systems and variations in usage patterns. The sub-optimal distribution of microservices may also cause an increase in network latencies. As a result, the application needs to be tuned for improved performance over time. The tuning of performance may also be necessary when other services are redeployed, and/or when new infrastructure becomes available.
Typically, the tuning of performance is performed manually as automated tools for performance tuning lack the ability to understand how the microservice instance of one microservice communicates with microservice instances of other microservices. The manual tuning of performance requires considerable skill and substantial time and effort. Moreover, the tuning of performance is currently performed solely based on static affinity rules, which do not account for variations in traffic patterns and changes to the system behaviors over time, leading to over-provisioning of resources and higher costs.
Accordingly, there is a need to facilitate tuning of the performance of microservices-based application to achieve optimum performance. Moreover, there is a need to automatically tune the performance of the application as and when required, while precluding human intervention.